As is known, a computing file system (FS) stores, organizes, manipulates and retrieves computer files and they data they contain. Many file systems are known and each has its own nuances for storing files and later retrieving them. Some of the more popular file systems include FAT, NTFS, UNIX file system (UFS), XFS, JFS, ReiserFS, HFS, ZFS, JFFS2, YAFFS, 9P, and extended files system (e.g., ext2, ext 3), to name a few.
To store data, file systems interact with storage devices, such as hard disks, flash memories, CD-ROM's etc. The devices can be local on a computing device maintaining the physical location of the files, or remote, such as on a network file server. In either, it is common to arrange the files in “sectors” and file system software (often integral with the operating system) organizes the sectors by keeping track of whether sectors are used, whether and how much space exists for future files, which sectors belong to which file, and the like. Other properties or attributes are also regularly kept in modern file systems. For example, it is now common to store a length of the data in the file, as well as the time that it was first created, last modified, last accessed, etc. Still other information includes device type (e.g., block, socket, etc.), file owner, access permission(s), author, checksums, etc.
Also, file systems typically utilize directories to associate file names with files. Usually, they connect the file name to an index in a file allocation table (FAT) in a DOS file system, or an inode in a UNIX-styled file system. Most modern directories are also hierarchical. While useful for a great many things, such as visual and practical file arrangement, they have limitations for finding certain files, storing and finding distinct files with duplicate file names, and utilizing multiple file names for the same file. They also require two or more items when searching and saving files, especially file name and pathname.
For example, in a hierarchy having a directory of “bar 1” and “bar 2,” two similar or distinct files can exist simultaneously with the same file name “foo” since their file pathnames are distinct, i.e., “bar1/foo” and “bar2/foo.” While some specialized file systems allow for files of the same name in the same directory, they force uniqueness values in their metadata to show the files as truly different. In other file systems, entering duplicate names forces users to rename their files to make them prima facie unique.
In any file system, users commonly utilize file names having meaning or relevance regarding the underlying data so that the files can be easily organized and found later during searching. They also commonly create multiple directories, each with sub-directories, each with meaningful file names. For example, “budget/2008/June” and “budget/2008/July” are relevant to, first, a budget of a family or company and, second, to monthly budgets, especially June and July in the year 2008. Later, upon subsequent searching for the monthly budget data for June and July, 2008, users know exactly where to look in the file system based on the names of the directories, sub-directories, and files.
However, some files need to belong to two or more directories to be found this way, which is why some file systems allow for “softlinks.” Softlinks, as are known, allow for what looks like a second file, but are mostly pointers to the first file with a different name or even a different directory, e.g., “budget/2008/June” and “expenses/2008/June” might be the same file.
In other architectures, some directories are known to be “flat.” That is, the files are not hierarchical, but are saved at the same root level. While avoiding some of the problems in the hierarchy architecture, they have unique other problems since every file must have a different name and, as files in the system grow, inefficiency abounds which makes it difficult for users to organize data into related groups. As Apple, Inc., quickly found out with their original, flat Macintosh File System (MFS), every file on disk had to have a unique name, even if they appeared to be located in separate folders in their save and find file dialog boxes. Its version did this with file management software, named Macintosh Finder, which created the hierarchy illusion in the folders. It was also eventually replaced with the Hierarchical File System (HFS), which supported true directories.
In other flat architectures, it has been known to “pad” fields with whitespace of fixed widths, or to delimit them by one or more separation characters. In “Unix-like” operating systems, some virtual file systems appear to make all the files on all the devices appear to exist in a single hierarchy. In some embodiments, this occurs by assigning a device name to each device, but such is not how the files on other devices are accessed. Rather, an operating system is first informed where in the directory tree those files should appear. This process is well known and called “mounting” a file system. Generally, only a system administrator (i.e. root user) may authorize mounting.
With the advent of modern search mechanisms, it is not uncommon for search tools to require search terms of file “name,” “content,” or both. However, if users are trying to locate files in voluminous systems, this is problematic since users often forget whether certain keywords were placed in the file name or in the content. It is especially difficult when users search for files created and saved by authors other than themselves.
Accordingly, a need exists in the art of file systems for overcoming the foregoing and other problems. More particularly, the need contemplates a filing system having improved file finding/searching and saving abilities, better file naming conventions, including allowing duplicate names for different files and multiple names for same files, and the avoidance of search/save complexities, such as needing file pathname(s). Naturally, any improvements along such lines should further contemplate good engineering practices, such as security, stability, ease of implementation, unobtrusiveness, useful user interface (UI) mechanisms, etc.